Parametric google-test for mapping validation#13281
Conversation
7931539 to
2dc1f20
Compare
5e3e7cf to
58f0867
Compare
fb7709b to
c85d371
Compare
bd81c8f to
a2de90e
Compare
|
This PR is marked as stale because it has been open 90 days with no activity. |
|
This PR is marked as stale because it has been open 90 days with no activity. |
|
I think we should get this improvement in! I have taken some time to rebase this branch against Let me know if you want me to submit it in a PR directly. |
|
The problem is that this PR slows down the test significiantly, because creating the list of mappings takes a lot of time. A hardcoded list shouldn't have this issue. |
|
what magnitude of slowdown are we talking about here? seconds? |
|
The whole testsuite needs about 2x time as before, because the list of mappings is calculate before every test (not only the test that depend on this parameter) |
|
oh yeah, then that is a significant problem. |
|
I have pushed a version with the mapping list computed directly in CMake. Only did MIDI as example, but keen to hear if we would want to go ahead with it. There is undoubtedly an overhead with running multiple tests, perhaps we could make it optional, so only the |
|
GTest must always work standalone without CTest, as GTest is what is used in IDEs. One of the challenges to achieve this ist to find the ./res/controller directory in all environments. |
|
Yes, this is what my solution does. It only finds the mapping at compile time to build the parameter list. Once built, |
Use CMake to collect mapping files at configure time and pass them compile definition.
…rollers/midi-components-0.0.js:140:\nTypeError: Cannot call method 'trigger' of undefined\n\nBacktrace: @file:///home/runner/work/mixxx/mixxx/res/controllers/midi-components-0.0.js:140\ntrigger@file:///home/runner/work/mixxx/mixxx/res/controllers/midi-components-0.0.js:139\nComponent@file:///home/runner/work/mixxx/mixxx/res/controllers/midi-components-0.0.js:53\nButton@file:///home/runner/work/mixxx/mixxx/res/controllers/midi-components-0.0.js:164\n%entry@file:///home/runner/work/mixxx/mixxx/res/controllers/Hercules-P32-scripts.js:109
|
Finally ready, thanks to the suggestion by @acolombier above! |
acolombier
left a comment
There was a problem hiding this comment.
Looking good, thanks for pushing this to the end! I haven't tested it yet
| if (this.connections[0] !== undefined) { | ||
| this.connections.forEach(function(conn) { | ||
| conn.disconnect(); | ||
| if (conn !== undefined) { |
There was a problem hiding this comment.
Is this an expected usecase? It does makes sense in the case of testing due to missing CO, but I assume that connections should only contain valid connections, else it would indicate a problem.
Should we add a console.warn to flag potentially failed connection?
There was a problem hiding this comment.
Detailed warnings are already implemented in engine.makeConnection:
mixxx/src/controllers/scripting/legacy/controllerscriptinterfacelegacy.cpp
Lines 276 to 290 in c10f342
But after the warning engine.makeConnection returns
undefined and the script continues.
| PUBLIC CONTROLLER_HID_MAPPINGS="${CONTROLLER_HID_MAPPINGS}" | ||
| PUBLIC CONTROLLER_MIDI_MAPPINGS="${CONTROLLER_MIDI_MAPPINGS}" | ||
| ) | ||
|
|
There was a problem hiding this comment.
DO we need to make the above conditional to HID, and BULK?
There was a problem hiding this comment.
I think the simplicity of the code is of more value than skiping 1 or 2 regular expressions during CMake configuration.
acolombier
left a comment
There was a problem hiding this comment.
LGTM! This seems to slow down the test run by about 30 seconds (for Ubuntu). That being said, the added value is worth the delay IMO.
Giving some time to let other member a chance to review this as well.
|
Merge? |
For debugging #11625 (comment) I modified the googletest setup for mapping validation to use a parametrized list of mappings.

While the results look nice in my IDE, where I can easily debug a single mapping validation test now:
I was disappointed to see that CTest combines all the single GTest instances:
I could solve that by using gtest_discover_tests in the CMakelist.txt, now the CTest output looks like this: